As application development projects grow larger, packages are becoming both increasingly important and cumbersome. For example, when changes are made to currently existing Advanced Business Application Programming™ (ABAP) software, the implication of such changes are difficult to foresee, which often causes problems in the future. Having an improved package can make the software's blueprint visible, which can make the changes to the software foreseeable and better protected against malicious changes.
FIG. 1 illustrates a prior art package 100. The package 100 is also known as development classes because it represents a group of objects 102, where each object 102 is assigned to a development class. Each development object 102, such as report, global class, data element, and table, is assigned to the package 100. The object 102 contains organizational attributes, such as person responsible, application component, etc., and technical attributes, such as transport layers, software component, etc. The package 100 also includes a package interface 104 to expose the object 102 to those who seek the object 102.
The package 100 is viewed as a capsule whose content is hidden to the outside. Any interaction with the package's content is accomplished through the development objects 102 that are exposed via an interface 104 of the respective package 100. Furthermore, the package 100 determines transport properties of development object 102 contained in it, such as whether the object 102 can be exported from the system, or whether it can be exported, and what are the target systems (using the assignment to a transport layer).
Referring now to FIG. 2, it illustrates nesting 200 of multiple packages 202, 208. As illustrated, a package 208 (e.g., subpackage) is nested into another package 202 (e.g., superpackage). When nesting 200, the subpackage 208 is visible only within its superpackage 202. This package nesting 200, for example, allows for structuring of packages 202, 208 by placing the development objects 210 needed only for a certain part of the implementation into a separate subpackage 208. The superpackage 202 not only exposes its own development objects 204 via its interface 206, but also exposes the objects 210 of its subpackage 208 through the subpackage's interface 212 and its own interface 206. Those development objects of the subpackage 208 that are not exposed at the superpackage's interface 206 are invisible outside the superpackage 202 and can only be used from within the superpackage 202.
Although the conventional package mechanism provides increasing flexibility for better structuring of software, and represents an essential tool for ensuring and tracking decoupling of software, further improvements to the existing package mechanism are needed. For example, the conventional package mechanism lacks new strategies with regard to handling generation of objects, interfacing, and enhancements to software. These limitations are further exasperated when different interfaces, modules, components, and/or services are used across the development project.